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Abstract 

Authentication can serve both for assigning responsibility and for 
giving credit. Some authentication protocols are adequate for one pur- 
pose but not the other. This paper explains the distinction between 
responsibility and credit, through several examples, and discusses the 
role of this distinction in the design and analysis of protocols. 
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1 Responsibility and Credit 



Authentication can serve both for assigning responsibility and for giving 
credit. An "authenticated" message M from a principal A to a principal B 
may be used in at least two distinct ways: 

• B may believe that the message M is being supported by A's authority. 
For example, suppose that B is a file server, A a client, and M a request 
to delete a file /. Then B may use A's identity as an argument to the 
access control decision of whether to delete /. 

• B may attribute credit for the message M to A. For example, suppose 
that B is running a contest, offering a prize to the principal that mails 
the factors for a large number. When B receives the message M as an 
entry, B may give credit for the entry to A. 

These two uses are sharply different, and require different concepts of au- 
thentication. Furthermore, some natural protocols are adequate for assign- 
ing responsibility but not for giving credit, and vice versa. We consider some 
of those protocols in this paper. 

When a new authentication protocol is designed, it is therefore prudent 
to state whether the protocol is intended to establish responsibility, credit, or 
both. Similarly, when an authentication protocol is analyzed, it is prudent to 
clarify whether its properties suffice for establishing responsibility or credit. 
However, a quick look at the literature (discussed below) suggests that this 
clarification is not often present. 

This paper explains the distinction between responsibility and credit, 
through several examples, and discusses the role of this distinction in the 
design and analysis of protocols. Papers by Gollman, Lowe, and others have 
shed light on several possible definitions of authentication [Gol96, Low97]. 
This paper does not attempt to review those studies, but aims to comple- 
ment them. 

The two facets of authentication are most clearly separate in proto- 
cols that rely on asymmetric cryptosystems, such as the RSA cryptosys- 
tem [RSA78]. We therefore take public-key protocols as examples. Al- 
though our list of examples is not meant to be comprehensive, we illustrate 
the distinction between responsibility and credit through several protocols of 
different styles. Our emphasis is not on classifying cryptographic techniques. 
(See [MvOV96, Chapter 12] for a helpful classification.) Rather, we focus on 
the higher-level guarantees that protocols provide to the applications that 
may rely on them. 
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The direct author of a message need not always be held responsible for 
the message or be given credit for it. In particular, a principal may delegate 
some part of its authority to another principal, taking responsibility for 
messages sent by the delegate (much like one can let a friend withdraw from 
one's bank account). Similarly, a principal may legitimately divert credit for 
its messages to another principal (much like one can deposit into a friend's 
bank account). Therefore, even when it is proved beyond a reasonable doubt 
that a principal sent a message, responsibility and credit may not follow. 
Responsibility and credit are thus distinct from non-repudiation of origin 
and other related concepts [ZG96, Roe]. 

2 Four Examples 

This section discusses four examples that illustrate the concepts of respon- 
sibility and credit, and their applications. The examples concern techniques 
that are common in published, useful protocols. In all four examples, re- 
sponsibility and credit for the messages between two parties is assigned by 
the parties themselves. For simplicity, we do not consider scenarios where a 
third party (for example, a judge) may assign responsibility or credit, but 
such scenarios could be interesting too. 

2.1 Signing a Public Key 

As a first example, we consider a simple protocol where a principal A creates 
a short-term key pair, sends the short-term public key to a principal B, 
signing it with its long-term secret key, then uses the short-term secret key 
for signing further messages: 

Message 1 A -» B : A, B, {K, A, B, T} K -i 
Message 2 A -> B : A, B, {{M} k -i} Kb 

Here M is an arbitrary message, T is a timestamp, Ka is A's long-term 
public key, is the corresponding secret key, K is A's short-term public 
key, and K^ 1 is the corresponding secret key. We use braces for signatures, 
as in {M} K -i, and for encryptions, as in {{M} k -i}k b . Message 1 is the 
core of the protocol; Message 2 appears only as an example of the use of K. 

In one interpretation of this protocol, Message 1 conveys that A takes 
responsibility for the key K, so B can blame A for any message signed with 
K^ 1 . Thus, the protocol fits applications that require responsibility for a 
message (or for a connection). For example, the protocol seems adequate 
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for the situation where B is a file server, A a client, and M a request 
to delete a particular file. It seems adequate even if A gives K^ 1 to a 
delegate, allowing the delegate to make requests on A's behalf (although 
delegation mechanisms where B knows the identity of the delegate may be 
preferable [L ABW92] ) . 

In a second interpretation of this protocol, B would assign credit to A for 
every message that is signed with K~ x . This interpretation is not justified, 
as the following would constitute an attack: 



Message 1 A -> B 

Message 1' C B 

Message 2 A -> B 

Message 2' C -> B 



A, B, {K, A, B, T} K -i 

C, B, {K, C, B, T} K \ 

A B, {{M} k -i}k b ° 
C, B, {{M} k -,} Kb 



(intercepted by C) 
(intercepted by C) 



Here C is an attacker who signs the public key generated by A. On receipt 
of M, we would have B give credit for M to C rather than to A. This 
sequence of messages constitutes an attack with the second interpretation, 
since it may result in erroneous credit to C. On the other hand, with the 
first interpretation, this sequence of messages may result in erroneous blame 
to C; it may also result in denial of service to A and B, but has no other 
direct negative impact on them. 

The protocol can be strengthened in a variety of ways. In particular, A 
may sign its own name with the secret key K -1 , for example as in: 



Message 1 A 
Message 2 A 



B: A,B,{K,A,B,T} K -i,{A} K -i 
B : A, B, {{M} k -i} Kb 



or 



Message 1 A -» B : A, B, {K, A, B, T} K -i 
Message 2 A -> B : A, B, {{A, M} k -i} Kb 

These modification do not prevent an attacker C from signing the key K 
with its key Kq ; however, C cannot sign its own name with K" 1 , since C 
does not have K . Therefore, the protocol becomes adequate for giving 
credit for M to A. 

We may say that, with these modifications, A proves possession of the 
secret key K^ 1 [MvOV96, Definition 12.7]. However, this statement should 
not be taken literally. For example, suppose that A is a user with a smart- 
card and that B is a server. The smart-card may sign a short-term key K 
generated by the workstation to which the smart-card is connected, and the 
workstation may sign the name A, while the user and the smart-card may 
never have access to the secret key K~ l . 
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Protocols similar to this one may be used for registering public keys. In 
this application, B is a certification authority and A is a client that enters 
a new public key K into .B's registry. It has been argued that, whenever a 
client is associated with a public key K, the client should prove possession 
of the corresponding secret key K^ 1 [MvOV96, Remark 13.23]. However, 
this view is not universal — it is not shared, in particular, in some recent 
public-key- infrastructure designs [E1197] . 

2.2 Encrypting a Session Key 

While the first example shows that a signature may lead to responsibility, 
the second example shows that an encryption may lead to credit, and that 
a decryption may lead to responsibility. 

We consider the situation where a principal A transmits a session key K 
(say, a DES key [DES77]) to another principal B, encrypting K under B's 
public key Kb, and including the name A along with K: 

Message 1 A -> B : {A, K} Kb 
Message 2 A -> B : {M} K 
Message 3 B -> A : {M'} K 

Messages 2 and 3 simply illustrate the use of the session key K for sending 
some messages, M and M'. We assume that both principals have means 
for recognizing and ignoring their own messages, so for example A will not 
mistake a replay of {M}k for a message from B. 

This protocol is adequate for applications that require responsibility for 
B, and perhaps for applications that require credit for A: 

• Only B can extract K from Message 1. Therefore, B can take respon- 
sibility for the use of K. Whenever A receives a message encrypted 
under K , if A did not generate the message itself, then A can be cer- 
tain that B generated the message, or that some principal to which B 
gave K generated the message. So A can hold B responsible for the 
message. 

• Since Message 1 yields no proof of ^4's identity, B does not know who 
else has K. Therefore, B should not send any secrets under K. We do 
not consider the issue of credit for B for lack of a compelling example 
where B would claim credit for public data. (Perhaps only secrets are 
worth claiming credit for.) 

• Since any principal could have produced Message 1, B cannot hold 
anyone responsible for messages from A encrypted under K. 
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• Nevertheless, by including its name in Message 1, A claims credit for 
messages encrypted under K. Of course, if A chooses K incompetently 
or maliciously, then another principal C might have K as well, and 
might also produce messages encrypted under K. Still, since A has K, 
and assuming that C sends those messages to A or that A is capable 
of intercepting them, A can read and produce those same messages. 
Therefore, (some) credit to A is justified. 

The last of these points indicates that this protocol may not be a solid 
basis for unqualified credit to A. The following alternative protocol provides 
a clearer case for credit to A and preserves the responsibility of B: 



Message 1 


A 


-» B : 


{ j a}k b 


Message 2 


B 


-» A : 


Jb 


Message 3 


A 


-» B : 


{M} K 


Message 4 


B 


-» A : 


{M'} K 



(K = H(J A ,J B ,A,Bj) 

where J a and Jb are random quantities invented by A and B, respectively, 
and K is computed by applying a one-way hash function H to the concate- 
nation of J a, Jb, and the names A and B. With this alternative protocol, 
A can still forward a message M received from another principal, of course, 
but A cannot pick a session key K in use by other principals. 

2.3 Making a Session Key from Encrypted Shares 

As a third example, we consider a protocol for obtaining a shared key from 
encrypted shares. The protocol has been applied in several contexts. It 
appears in the work of Lampson et al. [LABW92] , and it also appears as a 
component of Krawczyk's SKEME protocol [Kra96]. We adopt Krawczyk's 
name for this protocol: SHARE. 

SHARE enables two principals A and B to obtain a shared key, assuming 
that initially each knows the public key of the other {K A or Kb)- Each of 
the principals invents a random quantity (J A or Jb), as a "half key". Then 
the following exchange takes place: 

Message 1 A — > B : {J A }k b 
Message 2 B -> A : {Jb}k a 

After this exchange, the two principals A and B compute a shared key K 
by applying a one-way hash function to the concatenation of the half keys 
J A and J B . 

In his explanation of SHARE, Krawczyk says: 
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If A follows the protocol then she is assured that the shared key 
[. . . ] is not know to anyone except B (though A does not have 
the assurance that B knows the key). And analogously for B. 

These properties should not be interpreted literally (and it is not Krawczyk 
intention that they be interpreted literally [Kra97]). In fact, in their literal 
interpretation, these properties do not hold. Consider, for example, the 
following message sequence: 

Message 1 A — > B : {Ja}k b 
Message V B -> C : {Ja}k c 
Message 2 C -> A : {Jc}k a 

In this sequence, A sends a half key to B, who then sends the same half 
key to C. By whatever means, B makes C believe that Message V comes 
from A. Therefore, C replies to A with another half key. As a result of this 
exchange, both A and C compute a shared key; C believes that it is shared 
with A, while A believes that it is shared with B. 

Whether this scenario constitutes an attack depends on the use of the 
protocol. It constitutes an attack in applications where it can result in harm 
to the principals A and C, which follow the protocol. 

• In some situations, this scenario may cause some confusion, but no 
clear harm. As a result of .B's behavior, A may attribute C's requests 
to B, and lend them the weight of fTs authority. Moreover, A may 
inadvertently reveal some of -B's secrets to C. Thus, .B's behavior may 
harm B, but would not directly harm A or C. 

Note that B does not obtain the key that A and C compute. Therefore, 
B cannot learn C's secrets by decrypting the subsequent messages 
from C to A. (In this respect, this scenario is quite different from 
Lowe's attack on the Needham-Schroeder public-key protocol [Low96], 
although its structure is reminiscent of that attack.) 

• More concretely, A may be a file server, and B and C two of its clients. 
In this case, the confusion may result in some immediate damage to 
-B's files as a result of C's requests. Moreover, C may be able to read 
some of .B's files. 

Indirectly, however, there can also be some harm to C if C's requests 
are not sufficiently explicit. Because of the confusion, A may write 
some of C's data into -B's files. In a later session B can read these 
files, obtaining C's data. 
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• Finally, if A is running a contest, then it may think that a winning 
entry that arrives under K came from B when in fact it came from C. 

In short, SHARE is adequate for some applications that require responsibil- 
ity but not necessarily for applications that give credit. 

With some additional precautions, SHARE can be used in applications 
that give credit. For example, each message that an application encrypts 
under the shared key could include (bound in the encryption) the name of 
its source, who expects credit for this message if any credit is to be had at 
all. The inclusion of this name is a prudent measure in any case; it agrees 
with Principle 3 of [AN96]: 

If the identity of a principal is essential to the meaning of a 
message, it is prudent to mention the principal's name explicitly 
in the message. 

Thus, the issue of credit can be separated from the protocol for agreement 
on a key, and shifted to the use of the key. 

Alternatively, we can easily strengthen SHARE, preventing the scenario 
described above. One possible modification is to let K be the result of 
applying a one-way hash function to the concatenation of J a-, Jb, and the 
names A and B, as in section 2.2. Another one is to add messages where 
the two parties A and B prove knowledge of K, as in SKEME. 

Krawczyk does not view SHARE as a complete protocol, but only as a 
phase of SKEME: 

To be really meaningful this phase [SHARE] needs to be com- 
bined with the other phases of the protocol [SKEME] . 

One may instead argue that SHARE is meaningful on its own, although 
precautions are needed for its use, and elucidating its meaning requires sep- 
arating credit from responsibility. 

2.4 The Station-to-Station Protocol 

As a last example, we consider the Station-to-Station protocol [DvOW92] . 
This protocol is fairly well known, so we do not reproduce it or discuss it in 
detail. 

Basically, the Station-to-Station protocol consists of a signed Diffie- 
Hellman exchange [DH76] , where both parties sign the Diffie-Hellman shares, 
and where they confirm possession of the resulting session key by using it 
to encrypt the signed Diffie-Hellman shares. 
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Without the key confirmation, the protocol suffices for establishing re- 
sponsibility: each party may hold the other responsible for messages under 
the session key With the key confirmation, the protocol is also suitable for 
establishing credit. 

Although the Station-to-Station protocol may be rather attractive, it 
is not without alternatives. Other techniques for key confirmation could 
replace the encryption of the signed Difne-Hellman shares. Furthermore, 
the key confirmation could be postponed or avoided altogether if, whenever 
credit is wanted, each message encrypted under the session key would contain 
the name of its source. 

3 Discussion 

While the examples of the previous section may be somewhat confusing, 
they are fairly typical of the authentication field. As this section discusses, 
there does not seem to be a general agreement on the goals of authentication, 
or a systematic analysis of the guarantees that authentication mechanisms 
provide to higher-level applications. 

3.1 Design 

In the literature on protocol design, there seems to be a consensus that 
an authentication protocol should at least establish responsibility, probably 
because responsibility is crucial for access control. In the context of access 
control, the primary property of a secure channel from a principal is that 
the channel "speaks for" the principal [LABW92, ABLP93]. In essence, a 
channel C speaks for a principal A if A's authority backs every message on 
C. This semantics justifies the following axioms: 

• if A says that C speaks for A, then C does speak for A; 

• if C speaks for A and C says s, then A says s. 

These axioms are useful and sensible when "A says s" entails that A takes 
responsibility for s; but they would be unreasonable if 11 A says s" was meant 
to imply that A deserves credit for s. In access control, responsibility is 
largely separate from credit. 

There does not seem to be a consensus that an authentication protocol 
should also establish credit. Although the literature does not seem to con- 
tain an explicit, articulate debate about this issue, we can propose likely 
arguments for both sides. 
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• We may argue that, once an authentication protocol has set up a 
channel that speaks for a principal, it is easy to use the channel for 
establishing credit whenever the need arises. (For example, the prin- 
cipal may send its name on the channel; see sections 2.1 and 2.3.) So 
it is not essential that an authentication protocol establish credit. 

• On the other hand, we may say that stronger guarantees are better 
than weaker guarantees, particularly when protocols may be applied 
carelessly or in ways not fully anticipated by their designers. Estab- 
lishing credit is a matter of prudence. 

The latter argument may be prevailing. Popular Internet protocols (such 
as the SSL protocol [FKK96]) probably establish credit, although one may 
conjecture that applications rarely take advantage of this feature. 

3.2 Analysis 

Formal analyses seldom highlight the distinction between responsibility and 
credit, and the effect of a proof of possession of a secret key. There are some 
exceptions, for example in the work of van Oorschot and Syverson [v093, 
Sv094] . Elsewhere, the distinction between responsibility and credit seems 
to be made through decisions in the modelling of protocol participants. (See, 
for example, work based on process algebras [Sch96, Low96, AG97].) 

• Honest protocol participants are expected to follow the rules of the 
protocol faithfully, and not to try to obtain credit for messages that 
they did not generate themselves. A proof about honest protocol par- 
ticipants may show that a protocol establishes responsibility, but not 
credit. 

• When an attacker is included as protocol participant, the attacker is 
not forced to follow the rules of the protocol, and may attempt to get 
undue credit. A proof that concerns such an attacker can show that a 
protocol establishes credit. 

The protocols described in this paper should make good examples for fu- 
ture work on protocol analysis. While these protocols do not present any 
challenges of scale, they exhibit common subtleties. 

There seem to be indications that responsibility and credit are dual no- 
tions. For example, through simple protocols, a principal may take responsi- 
bility for the statements of another principal, or may defer credit for its own 
statements to another principal. Moreover, responsibility sometimes comes 



9 



with signatures, while credit sometimes comes with encryptions. A crisper 
understanding of this duality might lead to more regular protocol designs 
and to more systematic arguments about their correctness. 
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